The present invention relates to Advanced Configuration and Power Management. More particularly, the invention relates to managing PCI devices in conjunction with an Advanced Configuration and Power Management system.
Every computer has a few, if not many, devices that only the firmware interacts with. In most machines this is a thermal sensor, a memory controller, or perhaps an ASIC that controls the brightness of the LCD screen of a laptop. The firmware may interact with these devices in non-prescribed or prescribed ways. If the firmware is forced to use non- prescribed ways, like an SMI trap or a straight BIOS call, the operating system cannot guarantee that the computer will perform properly, and the user is more likely to experience a lockup or a crash. When the firmware uses prescribed ways, then the operating system can ensure that the interactions with the device happen in controlled and correct ways, which makes the computer vastly less likely to crash. One such prescribed way is through the use of ACPI (Advanced Configuration and Power Interface) Machine Language (AML) code to control the devices. ACPI is an open industry specification that defines a flexible and extensible interface for power management. The interface enables and supports power management through improved hardware and operating system coordination.
One way to allow firmware control of hardware devices is to put those devices on the Industry Standard Architecture (ISA) bus. The ISA bus is a non-Plug-and-Play bus, so the hardware manufacturer could put devices on it and leave the descriptions of those devices out of the firmware. Since the operating system relies on firmware to describe to it the undiscoverable devices, the operating system would never know about or use them, leaving them to be controlled purely by the firmware. However, the ISA bus is becoming less and less common in computers, and will eventually become extinct. For that reason, hardware manufacturers would like to implement these firmware-controlled devices on the Peripheral Component Interconnect (PCI) bus or xe2x80x9cMezzanine Busxe2x80x9d, which is much more widely supported. However, implementing these devices as PCI devices presents new challenges. For instance, the operating system attempts to use every PCI device that it can find in the machine. If a device driver is not available to control the PCI device, then the operating system treats this as an error situation. However, creating a device driver for each such device creates a burden on the hardware manufacturers that isn""t necessarily justified given the simplicity of the type of devices at issue.
To further complicate matters, the PCI Specification requires that PCI devices be dynamically configurable. PCI devices each include an address space called the Configuration Space. At offset 0xc3x9710 through offset 0xc3x9727, there are as many as six Base Address Registers, (BARs). These BARs contain the base address of a series of control registers (in I/O or Memory space) for the PCI device. A Plug and Play (PnP) operating system may change the values of these BARs at any time to relocate (or xe2x80x9crebalancexe2x80x9d) the PCI devices within the computer""s address space. For that reason, the firmware cannot read from or write to the control registers deterministically because the operating system may reassign the PCI device""s BAR at runtime. Furthermore, a PnP operating system automatically assigns ownership of the I/O and memory regions associated with the BARs to a device driver associated with the PCI device, adding to the need for a specific device driver for each PCI device. Moreover, an ACPI-compliant operating system does not allow firmware code to read from or write to regions that are owned by other device drivers.
These and other problems have prevented computer manufacturers from achieving an acceptable solution for supporting firmware-controlled devices. Thus, there is a need in the art for just such a solution.
Briefly stated, the present invention provides a system and method by which a PCI device may be controlled by firmware in an Advanced Configuration and Power Management system. More specifically, the present invention enables a PCI BAR Operation Region through which PCI devices may be accessed. A device connected to the PCI bus is described in firmware with AML that declares a PCI BAR operation region associated with the PCI device. A generic driver is loaded and registers itself to handle any access to or from the PCI device by means of the PCI BAR operation region. Essentially, the genetic driver is enumerated as a functional driver (FDO) for the PCI device. When a Plug-n-Play manager assigns base addresses to each PCI device on the PCI bus, the generic driver stores this information. Calls by the firmware to the PCI BAR operation region identify the PCI BAR number (i.e., the PCI device) and give an offset The generic driver resolves that information into an absolute memory or I/O address based on the current BAR assigned by the PnP manager and performs the requested access.
In this way, the PnP manager may rebalance the PCI devices without fear that the PCI devices will become unavailable or be xe2x80x9clostxe2x80x9d to the firmware. It should be noted that during a rebalance, the PCI Bar operation region is temporarily unavailable. Accesses of the operation region cannot be handled while the system is reprogramming the BARs. However, the operation region driver may xe2x80x9cqueuexe2x80x9d outstanding requests until the reprogramming is complete, with the caveat that the process of reprogramming the BARs cannot access the BARs to do so (thereby generating a circular set of references) since that would cause a deadlock. By creating a PCI BAR operation region, manufacturers of relatively-simple PCI devices are relieved of the burden of creating device-specific drivers.